Operations image product data set descriptions

Data Set Overview

A stereo anaglyph is a method of displaying stereo imagery quickly and conveniently using conventional display technology (no special hardware) and red/blue glasses. This is done by displaying the left eye of the stereo pair in the red channel, and displaying the right eye in the green and blue channels. An anaglyph data product simply captures that into a single 3-band color image, which can be displayed using any standard image display program with no knowledge that it is a stereo image. The red (first) band contains the left eye image, while the green and blue (second and third) bands each contain the right eye image (so the right image is duplicated in the file).

The Anaglyph method can also apply to multi-frame mosaic products. MIPL-generated mosaic Anaglyphs occasionally required some subtle pixel-shifting of the right eye mosaic data to improve the stereo effects. Mosaic Anaglyph products are distinguishable in the Mosaic RDR filename convention.

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

Anaglyphs are created manually from CAHV linearized Full Framed (FFL)stereo pair EDRs or mosaics. Often times the images are stretched prior to creating the anaglyph. After stretching, the images are converted to a VICAR cube, which creates a single multi-band image. The final step involves adding the PDS label.

Data

The RDR data product is comprised of radiometrically decalibrated and/or camera model corrected and/or geometrically altered versions of the raw camera data, in both single and multi-frame (mosaic) form. Most RDR data products will have PDS labels, or if generated by MIPL (OPGS), dual PDS/VICAR labels. Non-labeled RDRs include the Terrain products (Mesh and Wedge).

Software

The MIPL Mars Program Suite was used to generate these RDRs.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the Operations RDRs will be delivered to PDS on DVD.

Data Set Overview

A Disparity file contains 2 bands of 32-bit floating point numbers in the Band Sequential order (line, sample). Alternatively, line and sample may be stored in separate single-band files. The parallax, or difference measured in pixels, between an object location in two individual images (typically the left and right images of a stereo pair) is also called the disparity. Disparity files contain these disparity values in both the line and sample dimension for each pixel in the reference image. This reference image is traditionally the left image of a stereo pair, but could be the right image for special products. The geometry of the Disparity image is the same as the geometry of the reference image. This means that for any pixel in the reference image the disparity of the viewed point can be obtained from the same pixel location in the Disparity image.

The values in a Disparity image are the 1-based coordinates of the corresponding point in the nonreference image. Thus, the coordinates in the reference image are the same as the coordinates in the Disparity image, and the matching coordinates in the stereo partner image are the values is the Disparity image. Disparity values of 0.0 indicate no valid disparity exists, for example due to lack of overlap or correlation failure. This value is reflected in the MISSING_CONSTANT keyword.

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

This Operations RDR is produced by OPGS/MIPL using the Mars Suite of VICAR image processing software.

Data

2 bands, Float, DualPDS/VICAR (OPGS) binary file.

Software

The MIPL Mars Program Suite was used to generate these RDRs.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the Operations RDRs will be delivered to PDS on DVD.

Data Set Overview

EDRs and single-frame RDRs are described by a camera model. This model, represented by a set of vectors and numbers, permit a point in space to be traced into the image plane, and vice-versa.

EDR camera models are derived by acquiring images of a calibration target with known geometry at a fixed azimuth/elevation. The vectors representing the model are derived from analysis of this imagery. These vectors are then translated and rotated based on the actual pointing of the camera to represent the conditions of each specific image. The results are the camera model for the EDR.

The RAC and SSI use a CAHVOR model. The model is not linear and involves some complex calculations to transform line/sample points in the image plane to XYZ positions in the scene. To simplify this, the images are warped, or reprojected, such that they can be described by a linear CAHV model. This linearization process has several benefits:

1. It removes geometric distortions inherent in the camera instruments, with the result that straight lines in the scene are straight in the image.
2. It aligns the images for stereo viewing. Matching points are on the same image line in both left and right images, and both left and right models point in the same direction.
3. It facilitates correlation, allowing the use of 1-D correlators.
4. It simplifies the math involved in using the camera model.

However, it also introduces some artifacts in terms of scale change and/or omitted data (see the references). The linearized CAHV camera model is derived from the EDR's camera model by considering both the left and right eye models and constructing a pair of matched linear CAHV models that conform to the above criteria.

The image is then projected, or warped, from the CAHVOR/CAHVORE model to the CAHV model. This involves projecting each pixel through the EDR camera model into space, intersecting it with a surface (which matters only for Hazcams and is a sphere centered on the camera), and projecting the pixel back through the CAHV model into the output image.

C - The 3D position of the entrance pupil

A - A unit vector normal to the image plane pointing outward (towards C)

H - A vector pointing roughly rightward in the image; it is a composite of the orientation of the CCD rows, the horizontal scale, the horizontal center

V - A vector pointing roughly downward in the image; it is a composite of the orientation of the CCD columns, the vertical scale, the vertical center, and A.

If P is a point in the scene then the corresponding image locations x and y can be computed from:

x = ((P-C)H) / ((P-C)A)

y = ((P-C)V) / ((P-C)A)

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

This Operations RDR is produced by OPGS/MIPL using the Mars Suite of VICAR image processing software.

Single-frame RDRs are described by a camera model. This model, represented by a set of vectors and numbers, permit a point in space to be traced into the image plane, and vice-versa.

Data

1 band, 16-bit signed integer, dual PDS/VICAR (OPGS) binary file. The RDR data product is comprised of radiometrically decalibrated and/or camera model corrected and/or geometrically altered versions of the raw camera data, in both single and multi-frame (mosaic) form. Most RDR data products will have PDS labels, or if generated by MIPL (OPGS), dual PDS/VICAR labels. Non-labeled RDRs include the Terrain products (Mesh and Wedge).

The following is a list of the types of Linearized files along with the Product Type Identifier, which is an element in the formal RDR file name:

Data Product	Linearized
Full Frame EDR	FFL
Sub-frame EDR	SFL
Downsampled EDR	DNL
Thumbnail EDR	THN

Software

The MIPL Mars Program Suite was used to generate these RDRs.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the Operations RDRs will be delivered to PDS on DVD.

Data Set Overview

This data set contains images where multiple frames are mosaicked into a single RDR product. The methods for this process are applied by MIPL under OPGS, associating projections with the mosaicking process. It should be noted that these processes can be independent, and that governing methods and software can differ between OPGS and the other science instrument teams. For instance, it is possible that OPGS and other science teams' software will transform individual images to one of the projections discussed below, without involving any mosaicking. Detailed mathematical descriptions of the mosaic projections and algorithms will be available in a separate paper 'Mars Mosaic Projection Algorithms.'

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

The following is a description of each mosaic:

• Cylindrical Projection: the image is overlaid onto azimuth and elevation grid lines, with individual frame boundaries super imposed and annotated by number. In this case each pixel represents a fixed angle in azimuth and elevation. Rows are of constant elevation in Mars coordinates. The horizon is level, and columns begin clockwise from Mars north.
• Camera Point Perspective: a perspective projection with horizontal epipolar lines. The image view is as if the camera had a much larger field of view.
• Cylindrical-Perspective Projection: a 360 degree view projection similar to the Point Perspective mosaic except that this is like a pinhole camera which follows the mosaic in azimuth. The horizon is not level in order to preserve epipolar viewing.
• Polar Projection: concentric circles represent constant projected elevation. Mars nadir is at the convergent center and the horizon is corrected for lander tilt. North is up.
• Vertical Projection: the creation of this type of mosaic assumes that the field is a plane tangent to the Martian surface with up pointing north. This is not an orthorectified rendering, but was found to be useful for rapid initial orientation.
• Orthographic Projection: this type of mosaic is a generalization of the vertical projection intended primarily for use with Microscopic Imager data. It differs in that an arbitrary axis of projection (as well as X- and Y-axes in the plane of projection) can be specified.
• XYZ: this mosaic contains XYZ values for each pixel in the mosaic rather than intensity values. The inputs to the mosaic program are XYZ files (or individual X, Y, or Z components), and the pixels are interpreted in the same way - as the coordinate of the corresponding pixel in Cartesian space. Like XYZ images, they may consist of a single 3-band file with X, Y, and Z components, or separate 1 band files for each component. XYZ mosaics can be produced in any of the mosaic projections. Note: these mosaics have a consistent coordinate system used applied to each input image; the output mosaic may have only one coordinate system in which the XYZ values are defined.
• Surface Normal (UVW): similar in concept to XYZ mosaics, a UVW mosaic is simply a mosaic created from UVW (surface normal) input images. The pixels represent the surface normals at each point. Like Surface Normal (UVW) images, they can be single 3-band files or separate 1-band files for each component. As with XYZ mosaics, any projection may be used, and all output values must be defined in the same coordinate system.

Data

1 or 3 16-bit signed integer or Float, PDS (SOAS) or dual PDS/VICAR(OPGS) binary file.

Software

The MIPL Mars Program Suite was used to generate these RDRs.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the Operations RDRs will be delivered to PDS on DVD.

Data Set Overview

A Surface Normal (UVW) file contains 3 bands of 32-bit floating point numbers in the Band Sequential order. Alternatively, U, V and W may be stored in separate single-band files as a U Component RDR, V Component RDR and W Component RDR, respectively. The single component RDRs are implicitly the same as the UVW file.

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

The pixels in a UVW image correspond to the pixels in an XYZ file, with the same image geometry. However, the pixels are interpreted as a unit vector representing the normal to the surface at the point represented by the pixel. U contains the X component of the vector, V the Y component, and W the Z component. The vector is defined to point out of the surface (e.g. upwards for a flat ground). The unit vector can be referenced to any of the MER coordinate systems (specified by the DERIVED_IMAGE_PARAMS Group in the PDS label).

Most UVW images will contain holes, or pixels for which no UVW value exists. These are caused by many factors such as differences in overlap, correlation failures, and insufficient neighbors to compute a surface normal. Holes are indicated by U, V, and W all having the same specific value. Unlike XYZ, (0,0,0) is an invalid value for a UVW file, since they are defined to be unit vectors. Thus there is no issue with the MISSING_CONSTANT as there is with XYZ, where (0.0,0.0,0.0) is valid.

Data

Surface Normal (UVW) RDR: 3 bands, Float data type, DualPDS/VICAR (OPGS) binary file.

Surface Normal U-component RDR: 1 band, Float data type, PDS (SOAS) or dual PDS/VICAR (OPGS) binary file.

Surface Normal V-component RDR: 1 band, Float data type, PDS (SOAS) or dual PDS/VICAR (OPGS) binary file.

Surface Normal W-component RDR: 1 band, Float data type, PDS (SOAS) or dual PDS/VICAR (OPGS) binary file.

The RDR data product is comprised of radiometrically decalibrated and/or camera model corrected and/or geometrically altered versions of the raw camera data, in both single and multi-frame (mosaic) form. Most RDR data products will have PDS labels, or if generated by MIPL (OPGS), dual PDS/VICAR labels. Non-labeled RDRs include the Terrain products (Mesh and Wedge).

The following is a list of the types of Surface Normal RDRs along with the Product Type Identifier, which is an element in the formal RDR file name:

Data Product	Linearized	Non-Linearized
UVW (XYZ) Surface Normal RDR	UVW	UVL
UVW (XYZ) Surface Normal RDR (thumbnail)	UVT	UVN
U (X) Surface Normal RDR	UUU	UUL
U (X) Surface Normal RDR (thumbnail)	UUT	UUN
V (Y) Surface Normal RDR	VVV	VVL
V (Y) Surface Normal RDR (thumbnail)	VVT	VVN
W (Z) Surface Normal RDR	WWW	WWL
W (Z) Surface Normal RDR (thumbnail)	WWT	WWN

Software

The MIPL Mars Program Suite was used to generate these RDRs.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the Operations RDRs will be delivered to PDS on DVD.

Data Set Overview

There are multiple methods of performing radiometric correction, distinguished by the RADIOMETRIC_CORRECTION_TYPE keyword. The most common are TAMCAL, RACCAL, MIPLRAD, MIPLRAD2, and MIPLRAD3.

1. TAMCAL Method (SSI Team)

This refers to radiometric correction of SSI instrument data only, performed by the SSI instrument team (Texas A&M University and University of Arizona) using their suite of software tools. It is the most precise correction method applicable to SSI data.

There are 2 general types of SSI Radiometrically-corrected RDR products that are generated by the SSI instrument team: Radiance-calibrated and Radiance-factor calibrated. Additional details on the radiometric processing and calibration of SSI images can be found in the SSI Calibration Report.

1.1 Radiance-calibrated RDRs ('RAD', 'RAL')

The non-linearized RDRs are generated from EDRs. They have all of the major instrumental/environmental calibrations applied, such as bias removal, dark current removal, electronic shutter smear effect removal, flat field correction, and bad pixel repair. Then they have been scaled to absolute radiance units using pre-flight radiometric calibration coefficients. The units on these files are (W/m^2/nm/sr). An analogous RDR file type exists for the linearized (geometrically-corrected) SSI RDR as well, and it is labeled with the 'RAL' product type identifier to correspond with the 'RAD' type. In addition, floating point versions of this RDR may also be generated.

1.2. Radiance factor-calibrated RDRs ('IOF', 'IOL')

The non-linearized RDRs are generated from EDRs or 'RAD' RDRs. They have all the major instrumental/environmental calibrations applied and have been scaled to absolute radiance units as described above, and then have been divided by the absolute radiance of the Sun at the top of the Martian atmosphere within the appropriate SSI bandpass, to generate radiance factor, or 'I over F' values, where I is the radiance from the Martian scene and pi * F is the radiance from the Sun at the top of the Martian atmosphere (or on the surface, as determined by reflectance calibration targets. Since the solar radiance in the same units as the Mars scene radiance was divided out, these files are unitless but typically have values in the range of 0.0 to 1.0 (for example, average bright Mars soils exhibit I/F ~ 0.35 at 750 nm and I/F ~ 0.05 at 410 nm).

As with the 'RAD' RDR type, there exists a linearized version of the IOF type of radiometrically corrected RDR, called 'IOL'. A floating point version of this RDR may also be generated.

2. RACCAL Method (RAC Team)

This refers to radiometric correction of RAC instrument data only, performed by the RAC instrument team (MPS) using their suite of RACCAL software tools. It is the most precise correction method applicable to RAC data. Note that radiometric correction of MECA-OM instrument data will be performed using the same tools employed for the RACCAL method.

The RAC/OM calibration steps performed by the RACSoft package are described below:

1. The bad pixel removal state replaces a number of pixels marked bad because of dust grains on the CCD or hot electron production. The bad pixels are replaced by an interpolated value based on the surrounding pixels.

2. The bias subtraction state subtracts the ADC digital offset from the image.

3. The RAC and the OM uses an electronic shutter where the image data is fast clocked to a covered area on the CCD at the end of the exposure. During the fast clocking each row experiences addition light from other parts of the scene. The electronic shutter correction subtracts from row N the summed DN signal of row 0 to N-1 scaled by the time it takes to clock a row one step on the CCD.

4. The dark current correction subtracts an estimated mean value of dark current based on the temperature of the CCD. This simple scheme (as compared to the SSI) is used because the RAC and OM has a very low dark current production under Mars conditions.

5. The flatfield correction divider the image by the relevant flatfield for the given focus motor step.

6. The OM calibration is finished after the flat field correction since good absolute calibration data is not available for the OM.

7. The final step of the RAC calibration is to divide the image by the absolute calibration constant for the given focus motor step. The calibration constant is given by the ground absolute calibration at focus motor step 306 (near infinite focus) and a correction factor derived for the change in instantaneous field of view between focus step 306 and the active focus step.

3. MIPLRAD, MIPLRAD2, MIPLRAD3 Methods

These refer to radiometric correction of any camera instrument data systematically performed by MIPL (OPGS at JPL) to meet tactical time constraints imposed by Arm Planners. The resulting rad-corrected RDRs are integrated into terrain mesh products used for RA trench digging. For SSI and RAC instrument data, these methods are less precise than the TAMCAL and RACCAL methods previously discussed. The MIPL radiometrically-corrected RDR filenames carry the product type designators RAD (non-linearized) or RAL (linearized).

MIPLRAD, MIPLRAD2, and MIPLRAD3 are first-order corrections only and should be considered approximate. All three apply the following corrections: dark current, temperature-compensated responsivity, exposure time, binning correction, and flat field. The result is calibrated to physical units for PHX of W/m^2/nm/sr. The actual algorithm and equations used for the three MIPLRAD's are in the data product SIS [ALEXANDERETAL2008]. In all cases, ALL_CAPITALS serve to denote keyword names in the PDS label.

The only difference between the three MIPLRAD methods is in the dark current calculation that is used. MIPLRAD uses a dark current calculation developed by Adam Shaw at the University of Arizona. MIPLRAD2 (the default) uses a calculation developed by Mark Lemmon at Texas A&M University. MIPLRAD3 uses the Lemmon calculation with a simplification for efficiency (described in the data product SIS).

Dark current applies only to SSI. RAC dark current is assumed to be 0 in all three methods.

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

Phoenix SSI RDRs are considered Level 3 (Calibrated Data equivalent to NASA Level 1-A), Level 4 (Resampled Data equivalent to NASA Level 1-B), or Level 5 (Derived Data equivalent to NASA Level 1-C, 2 or 3). The RDRs are to be reconstructed from Level 2 edited data, and are to be assembled into complete images that may include radiometric and/or geometric correction.

Phoenix SSI instrument EDRs and RDRs will be generated by JPL's Multimission Instrument Processing Laboratory (MIPL) as part of the OPGS subsystem of the Phoenix GDS. RDRs will also be generated by the SSI science instrument team at the SOC facility at the University of Arizona, as well as at its home institution, Texas A&M.

RDR data products will be generated by, but not limited to, MIPL using the Mars Suite of VICAR image processing software at JPL, and the SSI science instrument team using TAMCAL and RACCAL software at the SOC facility at the University of Arizona and at the team's home institution at Texas A&M University. The RDRs produced will be 'processed' data. The input will be one or more Camera EDR or RDR data products and the output will be formatted according to the data product SIS [ALEXANDERETAL2008]. Additional meta-data may be added by the software to the PDS label.

Data

RDR products generated by MIPL will have a VICAR label wrapped by a PDS label, and their structure can include the optional EOL label after the binary data. RDR products not generated by MIPL may contain only a PDS label. Or, RDR products conforming to a standard other than PDS, such as JPEG compressed or certain Terrain products, are acceptable without a PDS header during mission operations, but may not be archivable.

The RDR data product is comprised of radiometrically decalibrated and/or camera model corrected and/or geometrically altered versions of the raw camera data, in both single and multi-frame (mosaic) form. Most RDR data products will have PDS labels, or if generated by MIPL (OPGS), dual PDS/VICAR labels. Non-labeled RDRs include JPEG compressed products and the Terrain products.

Software

The MIPL Mars Program Suite was used to generate these RDRs, as well as the TAMCAL and RACCAL software suites.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the SSI Operations RDRs will be delivered to PDS on DVD.

Data Set Overview

A Range (distance) file contains 1 band of 32-bit floating point numbers. The pixels in a Range image represent Cartesian distances from a reference point (defined by the RANGE_ORIGIN_VECTOR keyword in the PDS label) to the XYZ position of each pixel. This reference point is normally the camera position as defined by the C point of the camera model. A Range image is derived from an XYZ image and shares the same pixel geometry and XYZ coordinate system. As with XYZ images, range images can contain holes, defined by MISSING_CONSTANT. For MER, this value is 0.0.

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

Phoenix SSI RDRs are considered Level 3 (Calibrated Data equivalent to NASA Level 1-A), Level 4 (Resampled Data equivalent to NASA Level 1-B), or Level 5 (Derived Data equivalent to NASA Level 1-C, 2 or 3). The RDRs are to be reconstructed from Level 2 edited data, and are to be assembled into complete images that may include radiometric and/or geometric correction.

Phoenix SSI instrument EDRs and RDRs will be generated by JPL's Multimission Instrument Processing Laboratory (MIPL) as part of the OPGS subsystem of the Phoenix GDS. RDRs will also be generated by the SSI science instrument team at the SOC facility at the University of Arizona, as well as at its home institution, Texas A&M.

RDR data products will be generated by, but not limited to, MIPL using the Mars Suite of VICAR image processing software at JPL, and the SSI science instrument team using TAMCAL and RACCAL software at the SOC facility at the University of Arizona and at the team's home institution at Texas A&M University. The RDRs produced will be 'processed' data. The input will be one or more Camera EDR or RDR data products and the output will be formatted according to the data product SIS [ALEXANDERETAL2008]. Additional meta-data may be added by the software to the PDS label.

Data

RDR products generated by MIPL will have a VICAR label wrapped by a PDS label, and their structure can include the optional EOL label after the binary data. RDR products not generated by MIPL may contain only a PDS label. Or, RDR products conforming to a standard other than PDS, such as JPEG compressed or certain Terrain products, are acceptable without a PDS header during mission operations, but may not be archivable.

The RDR data product is comprised of radiometrically decalibrated and/or camera model corrected and/or geometrically altered versions of the raw camera data, in both single and multi-frame (mosaic) form. Most RDR data products will have PDS labels, or if generated by MIPL (OPGS), dual PDS/VICAR labels. Non-labeled RDRs include JPEG compressed products and the Terrain products.

Software

The MIPL Mars Program Suite was used to generate these RDRs.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the Operations RDRs will be delivered to PDS on DVD.

Data Set Overview

An RA Reachability map contains information about whether or not the instruments on the RA can 'reach' (contact or image) the object or location represented by each pixel in the scene. It is derived from the XYZ and Surface Normal (UVW) products.

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

The geometry of the reachability map matches the linearized reference, XYZ, and Surface Normal (UVW) images, in that each pixel in the file directly corresponds to the pixel at the same location in the other products.

The reachability map is a 12-band byte image in standard Band Sequential order. Thus for each pixel there are 12 values. These values represent reachability for each of the 6 RA instrument placements in each of its 2 configurations. The mapping between band number and instrument/configuration is given by the INSTRUMENT_BAND_ID and CONFIGURATION_BAND_ID labels, and is summarized in Table 5.2.6 of the data product SIS [ALEXANDERETAL2008].

The value of the pixel is interpreted according to the instrument. For SCOOP, 0 means the pixel is not reachable in that configuration, while any other number represents the maximum preload in integer Newtons that can be applied at that point. For all other instruments, 0 means the pixel is not reachable by that instrument in that configuration, while 255 means that the pixel is reachable.

Software

The MIPL Mars Program Suite was used to generate these RDRs.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the Operations RDRs will be delivered to PDS on DVD.

Data Set Overview

The roughness map contains surface roughness estimates at each pixel in an XYZ image. The roughness is computed as the maximum peak-to-peak deviation from the local plane. Units are meters; that is, a pixel value of 0.05 means that the local surface about that pixel has a maximum peak-to-peak deviation along the surface normal by 0.05m (5cm). Roughness values above some useful threshold (maximum roughness) are clipped to that threshold. If a roughness could not be computed for a pixel (e.g. because of lack of range data, or too much noise in the range data), then the roughness value at that pixel will be set to the bad roughness value (which must be greater than maximum roughness).

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

Phoenix SSI RDRs are considered Level 3 (Calibrated Data equivalent to NASA Level 1-A), Level 4 (Resampled Data equivalent to NASA Level 1-B), or Level 5 (Derived Data equivalent to NASA Level 1-C, 2 or 3). The RDRs are to be reconstructed from Level 2 edited data, and are to be assembled into complete images that may include radiometric and/or geometric correction.

Phoenix SSI instrument EDRs and RDRs will be generated by JPL's Multimission Instrument Processing Laboratory (MIPL) as part of the OPGS subsystem of the Phoenix GDS. RDRs will also be generated by the SSI science instrument team at the SOC facility at the University of Arizona, as well as at its home institution, Texas A&M.

RDR data products will be generated by, but not limited to, MIPL using the Mars Suite of VICAR image processing software at JPL, and the SSI science instrument team using TAMCAL and RACCAL software at the SOC facility at the University of Arizona and at the team's home institution at Texas A&M University. The RDRs produced will be 'processed' data. The input will be one or more Camera EDR or RDR data products and the output will be formatted according to the data product SIS [ALEXANDERETAL2008]. Additional meta-data may be added by the software to the PDS label.

Data

RDR products generated by MIPL will have a VICAR label wrapped by a PDS label, and their structure can include the optional EOL label after the binary data. RDR products not generated by MIPL may contain only a PDS label. Or, RDR products conforming to a standard other than PDS, such as JPEG compressed or certain Terrain products, are acceptable without a PDS header during mission operations, but may not be archivable.

The RDR data product is comprised of radiometrically decalibrated and/or camera model corrected and/or geometrically altered versions of the raw camera data, in both single and multi-frame (mosaic) form. Most RDR data products will have PDS labels, or if generated by MIPL (OPGS), dual PDS/VICAR labels. Non-labeled RDRs include JPEG compressed products and the Terrain products.

Software

The MIPL Mars Program Suite was used to generate these RDRs.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the Operations RDRs will be delivered to PDS on DVD.

Data Set Overview

An XYZ file contains 3 bands of 32-bit floating point numbers in the Band Sequential order. Alternatively, X, Y and Z may be stored in separate single-band files as a X Component RDR, Y Component RDR and Z Component RDR, respectively. The single component RDRs are implicitly the same as the XYZ file, which is described below. XYZ locations in all coordinate frames for Phoenix are expressed in meters unless otherwise noted.

The pixels in an XYZ image are coordinates in 3-D space of the corresponding pixel in the reference image. This reference image is traditionally the left image of a stereo pair, but could be the right image for special products. The geometry of the XYZ image is the same as the geometry of the reference image. This means that for any pixel in the reference image the 3-D position of the viewed point can be obtained from the same pixel location in the XYZ image. The 3-D points can be referenced to any of the Phoenix coordinate systems (specified by DERIVED_IMAGE_PARAMS Group in the PDS label).

Most XYZ images will contain holes, or pixels for which no XYZ value exists. These are caused by many factors such as differences in overlap and correlation failures. Holes are indicated by X, Y, and Z all having the same specific value. This value is defined by the MISSING_CONSTANT keyword in the IMAGE object. For the XYZ RDR, this value is (0.0,0.0,0.0), meaning that all three bands must be zero (if only one or two bands are zero, that does not indicate missing data).

More information is found in ALEXANDERETAL2008, LEMMONETAL2007, and LEMMONETAL2008.

Processing

Phoenix SSI RDRs are considered Level 3 (Calibrated Data equivalent to NASA Level 1-A), Level 4 (Resampled Data equivalent to NASA Level 1-B), or Level 5 (Derived Data equivalent to NASA Level 1-C, 2 or 3). The RDRs are to be reconstructed from Level 2 edited data, and are to be assembled into complete images that may include radiometric and/or geometric correction.

Phoenix SSI instrument EDRs and RDRs will be generated by JPL's Multimission Instrument Processing Laboratory (MIPL) as part of the OPGS subsystem of the Phoenix GDS. RDRs will also be generated by the SSI science instrument team at the SOC facility at the University of Arizona, as well as at its home institution, Texas A&M.

RDR data products will be generated by, but not limited to, MIPL using the Mars Suite of VICAR image processing software at JPL, and the SSI science instrument team using TAMCAL and RACCAL software at the SOC facility at the University of Arizona and at the team's home institution at Texas A&M University. The RDRs produced will be 'processed' data. The input will be one or more Camera EDR or RDR data products and the output will be formatted according to the data product SIS [ALEXANDERETAL2008]. Additional meta-data may be added by the software to the PDS label.

Data

RDR products generated by MIPL will have a VICAR label wrapped by a PDS label, and their structure can include the optional EOL label after the binary data. RDR products not generated by MIPL may contain only a PDS label. Or, RDR products conforming to a standard other than PDS, such as JPEG compressed or certain Terrain products, are acceptable without a PDS header during mission operations, but may not be archivable.

The RDR data product is comprised of radiometrically decalibrated and/or camera model corrected and/or geometrically altered versions of the raw camera data, in both single and multi-frame (mosaic) form. Most RDR data products will have PDS labels, or if generated by MIPL (OPGS), dual PDS/VICAR labels. Non-labeled RDRs include JPEG compressed products and the Terrain products.

Software

The MIPL Mars Program Suite was used to generate these RDRs.

Media/Format

The data set will initially be delivered and kept online. Upon Mission completion, the Operations RDRs will be delivered to PDS on DVD.